What was broken
The previous PM-4151 follow-up suppressed active Marathon Match final columns and negative scores, but the final score fallback still depended on final_review.aggregateScore being non-null. If a final review row exists without a valid non-negative score, the query could still fall back to stale submission.finalScore.

Root cause
The final review lateral subquery only projected aggregateScore, so the scoring CASE could not distinguish no final review row from a final review row that exists but is not usable for export.

What was changed
Projected a has_final_review flag from the final review lateral subqueries for submitter, valid submitter, and winner exports. The Marathon Match final score CASE now falls back to submission.finalScore only when no final review row exists, while existing final review rows with negative or otherwise unusable scores export null.

Any added/updated tests
Updated the challenge export SQL regression spec to require the final review presence guard across submitter, valid submitter, and winner SQL.

What was broken
The previous PM-4151 follow-up suppressed active Marathon Match final columns and guarded final review fallbacks, but failed or deleted Marathon Match submissions could still influence score output. Positive initialScore/finalScore fallbacks from failed submissions could leak stale scores, and a newest failed submission with no usable score could mask an earlier valid scored run.

Root cause
The challenge export SQL filtered negative review summation scores, but the submission.initialScore and submission.finalScore fallback paths did not check reviews.submission.status. The submitter and valid submitter ranking CTEs also selected the newest submission before checking whether it had any usable Marathon Match score.

What was changed
Added failed/deleted submission status guards before using Marathon Match provisional and final score fallbacks in submitter, valid submitter, and winner exports.
Changed Marathon Match submitter and valid submitter score selection to skip rows where both provisionalScore and finalScore are unavailable, so the latest usable scored run is used instead of a failed no-score run.
Updated the challenge user DTO documentation to describe the latest non-failed scored submission behavior.

Any added/updated tests
Updated src/reports/challenges/challenge-export-sql.spec.ts to cover failed/deleted status guards, provisional initialScore fallback, and latest usable score selection for Marathon Match submitter exports.

What was broken
The previous PM-4151 follow-up blocked failed/deleted Marathon Match submissions and guarded final score fallback, but a failed provisional review row could still leak stale score data. If the latest provisional review summation had a negative score, the SQL filtered that row out before fallback logic and then used submission.initialScore or an older positive provisional row.

Root cause
The provisional review lateral queries only selected non-negative reviewSummation rows, so the CASE expression could not distinguish no provisional review from a latest failed provisional review. The final score path already had a has_final_review guard, but the provisional score path did not have the same guard.

What was changed
Added a has_provisional_review guard to submitter, valid submitter, and winner exports. The reports now use the latest provisional review row, return the score only when that row is non-negative, and only fall back to submission.initialScore when no provisional review row exists.

Any added/updated tests
Updated src/reports/challenges/challenge-export-sql.spec.ts to assert the provisional review guard and prevent pre-filtering negative provisional review rows before fallback logic runs.